home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
inet
/
scc
/
9222
< prev
next >
Wrap
Text File
|
1992-08-24
|
14KB
|
248 lines
**************************************************************************
Security Bulletin 9222 DISA Defense Communications System
August 25, 1992 Published by: DDN Security Coordination Center
(SCC@NIC.DDN.MIL) 1-(800) 365-3642
DEFENSE DATA NETWORK
SECURITY BULLETIN
The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
Coordination Center) under DISA contract as a means of communicating
information on network and host security exposures, fixes, and concerns
to security and management personnel at DDN facilities. Back issues may
be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
using login="anonymous" and password="guest". The bulletin pathname is
scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. scc/ddn-security-9222).
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
! !
! The following message is being relayed unedited via the !
! Defense Information Systems Agency's Security Coordination !
! Center distribution system as a means of providing DDN !
! subscribers with useful security information. !
! !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
"ALIENS 4": Epilogue
Dave Bouwer
23 Aug 92
On August 15, 1992, an alert for what was believed to be a new
"polymorphic" or "adaptive" virus strain was posted. This virus was
detected on a Macintosh IIci running System 7 at the Space Environment
Laboratory in Boulder, Colorado. I was the researcher at NOAA/SEL that
originated the alert, and I assume full responsibility for it.
To make a long story short, "Aliens 4" is a ghost--that is, it was either
a legitimate description or a peculiar combination of multiple
viruses and system software problems. In any case, two weeks of
work have failed to reproduce the original virus, and the alert needs
to be canceled.
For interested readers, I'm describing the circumstances that led
to the alert and giving some of my personal reflections. I hope to be
as honest as possible in this description so that others in a similar
situation can learn from my experience. None of the views here
represent those of NOAA or anyone else.
The Space Environment Lab (SEL) is an amalgam of talented physicists,
computer specialists, students, and administrative personnel. We do
no classified work, but provide important near-real-time forecasts of the
solar-terrestrial environment in addition to performing general research
in solar-terrestrial physics. A potential "hacker" has no need to raid
our systems: We are delighted to provide data nearly free of charge!
The computer environment at SEL is a complex combination of real-time
systems, super-computer links, high-end workstations, personal computers,
and a strained ethernet network tying everything together. SEL's extremely
capable staff are always trying, like most shops, to catch up on a
demanding backlog of new systems, upgrades, bugs, programming, etc.
We deal with an enormous amount of data: About 5 GB a day come through our
Services division alone.
I have been active in the computer sciences for nearly 20 years as a
developer, systems manager, and high-end user. While I am a long
way from "guru" status, I have a long string of experiences and
considerable education in government, university, and private industry.
About 50% of my time is devoted to my research in the time series analysis
of solar variability; the rest is spent in putting together the latest
in systems for scientific research.
In other words, it was not without careful consideration or some
expertise that I escalated the virus alert to a national level: the
consequences of not alerting others seemed VERY serious, and I was
nearly certain of what I had observed.
Generally, at SEL, we have tended to worry little about computer
security and have implemented only the basic measures, usually as
an afterthought. Our priority is to get the job done, and most users
in the lab manage their own systems both by choice and necessity.
However, in the last year the MS-DOS systems have seen two infections:
the infamous "Stoned" and "Michelangelo" viruses. Our concern about data
security is beginning to increase. After all, we do work just down
the street from a major university with a large computer science department!
The nine Macintosh systems are all less than a year old, and there
have seldom been any problems (least of all viruses). The "Lab Mac,"
which was available in a general computer lab area for visiting staff,
students, etc., has been one of my responsibilities. Since I much prefer
doing my papers and memos on the Mac instead of on my desk-top DECstation,
I frequently used it and kept it working well (I have been using a Mac for
about 5 years altogether, with a long history of VAX/VMS systems and some
Unix). About once a month, or whenever a peculiar problem would emerge,
I would run various combinations of our older anti-viral programs over all
the files, and I had never found a problem. I was over-confident that our
systems were unlikely to be seriously infected.
I discovered the virus on Saturday, August 8, 1992, when I noticed a
MandelZot Fractal application on the Lab Mac. Obviously, the neophyte
students were doing what every new computer science student seems to do
on a nice graphics system: making pictures for their dorm rooms! Such
creative endeavors are not to be discouraged: they often generate enthusiasm
and lead to new ideas. When I clicked on the application to see how they
were doing, the application alerted me to an infection (ALL applications
should do that!).
Not too worried and a little amused, I began to check it out. The
fractal application was last modified August 17, 1992, at 11:50 PM.
(somebody was in very late!) Interferon informed me that a "Type 2"
error was found in the System, Finder, MandleZot, Photoshop, Canopener,
Mac Profiler, Norton, System Sleuth, and Interferon (now that doesn't
exactly instill a secure feeling!). I was the one running all the
applications, so I figured I had a VERY infected system. Since it was
a Saturday, and I had a date, I put a notice on all the users' Macs
(I did not know whether the virus had propagated via the network), posted
a Lab-wide bulletin, and physically disconnected the Ethernet connections
from all the Macs. I shut down the Pathworks process running on our
Micro VAX/VMS server.
Sunday I came in to work on the problem (so much for my day of fly-fishing
my favorite river!). I ran Virus Rx 1.6, and it immediately became infected
(I can't recall all that it found). Next, I tried Disinfectant 2.4.
It reported what the Interferon run the day before had reported, identifying
the virus as an nVIR A strain. I decided to wait until Monday to talk to our
local NIST experts (we work in a large facility with an excellent networking
staff). I began putting together a new Mac we had just received, planning
to use it as a "test" machine. I also started planning how to campaign for
new Lab computer security measures: the long-term implications were
beginning to sink in!
I issued a stronger Lab-wide memo telling users they MUST back up their
files NOW. I disabled all Macs and told users to see me before starting
their systems. As you can imagine, this directive was not received well
the next day. In my overwhelming fear of lost data, I decided to err on
the side of caution. This was my first mistake: over-reacting and creating
an atmosphere of panic.
Monday, amidst countless user problems, I managed to sit down at the
infected machine with the local security guru. He came armed with the
latest versions of SAM and Norton. By then, there were dozens of reports
of printers not working, system crashes, odd screens, and disk drives
not working. At this point, I was becoming convinced that at least 3 Macs
were infected. Only the System 6 Mac's seemed problem-free. I suspected
that our local Ethernet network was carrying the virus somehow. This was
mistake number two: When users panic, every glitch that would normally be
ignored becomes a symptom of the virus. I mis-diagnosed the extent of the
problem on the basis of heresy, and not on my own direct experience.
Since one of my bosses -- the one who approves all my recommended
purchases -- was out of town, I broke the rules and had the division
secretary rush-order $1800 of SAM and Norton software. Mistake
number three: potential loss of data in the organization may not be
grounds for overstepping one's authority.
First we ran SAM (version 2.8 or 2.9). It reported the nVIR A strain as
the other diagnostic software had on the previous day. My NIST
colleague asked if I had another infected system or disk, and I said I
was sure I did. Mistake number four: I should have made absolutely certain
I had copies of the suspected virus. Other people will want to see any
reported virus.
We then told SAM to go ahead and eradicate the virus. It said it had
done so, without a problem. We ran SAM again, and here was where all my
alarms went off: On the second run, all the prior infected files and a
few new ones (the infected Versaterm Client application was the most ominous)
were infected with the MBDF A virus!
We ran SAM again, telling it to fix the files. Again, it said it did so
without any problems. Since we were running from write-locked floppies,
the system had to re-boot. When it came back up, my external LaCie drive
would not mount. The internal hard drive seemed to have no more problems.
My NIST colleague could only tell me what I already knew: I had a problem!
I consulted with another Mac expert, and he informed me about the new
adaptive or polymorphic viruses. Then an alert user gave me the new IEEE
Spectrum issue on data security (an excellent treatment in my opinion).
I became convinced I had at least a 50% chance of having a polymorphic
virus, and that's when I notified CERT of the ALIENS 4 virus (I came up
at the last minute with the name: I felt I had to call it something!).
Mistake number five was in jumping to a conclusion too soon.
Now it's two weeks later. Despite seriously overdue projects, I have
worked entirely on:
(1) Rebuilding the infected system after erasing the drives
(implementing the new 7.01, Pathworks 1.1, and removing
all but the DECnet and FTP network extensions).
(2) Trying to find the infected disk that started it all,
or at least SOME copy of it.
(3) Defending against management, user, and network criticisms.
(4) Campaigning for new resources for new Lab-wide computer security
measures.
So far I've only successfully completed (1), and I'm giving up on the
other three tasks. It's very hard to maintain political and technical
clout after getting labeled as a "Chicken-Little." I do know that a
department in the University has Macs riddled with the nVIR A strain and a
copy of an X-rated script that MIGHT be used as a Trojan horse (I will be
forwarding copies of that virus and the script to Symantec, Apple, and CERT,
but I believe they will see nothing other than a simple nVIR A strain and
a script of poor taste.) Other than the normal "glitches," there has been
no additional evidence of an infection.
To this day I believe the Lab had a new viral strain that posed a serious
risk. However, I still ask myself whether I either: (a) saved the lab and
others from catastrophic data loss, or (b) thoroughly embarrassed the
Lab and myself. I'm sure (b) is true, but I guess I'll never know about (a).
I still maintain that the highest priority, when data loss looms and
confusion and fear begin to overwhelm the beleaguered system manager,
is to protect the data. Yet I should have been more careful in deciding
to escalate the alarm.
In conclusion, because I am unable to reproduce the virus, ALIENS 4 is
just a "ghost." What we all have to ask ourselves is: Is ALIENS 4 a
ghost of "Christmas Future?" If I did observe a polymorphic or adaptive
virus coming in on some innocuous Trojan horse, how could anyone else know
it? And if the consequences of a false alarm are too severe, who would
risk their career by reporting a "potential threat"? Finally, how are we
going to defend ourselves against this kind of mutating computer threat (if
it indeed becomes realized) in departments already straining their resources
to the limits?
I leave these questions to the readers of this confessional. I've got a
very serious backlog of work to do.
Sincerely,
Dave Bouwer.
****************************************************************************
* *
* The point of contact for MILNET security-related incidents is the *
* Security Coordination Center (SCC). *
* *
* E-mail address: SCC@NIC.DDN.MIL *
* *
* Telephone: 1-(800)-365-3642 *
* *
* NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST, *
* Monday through Friday except on federal holidays. *
* *
****************************************************************************